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Handling of Internet-Drafts by IETF Working Groups 
Abstract 


The productive output of an IETF working group is documents, as 
mandated by the working group’s charter. When a working group is 
ready to develop a particular document, the most common mechanism is 
for it to "adopt" an existing document as a starting point. The 
document that a working group adopts and then develops further is 
based on initial input at varying levels of maturity. An initial 
working group draft might be a document already in wide use, or it 
might be a blank sheet, wholly created by the working group, or it 
might represent any level of maturity in between. This document 
discusses how a working group typically handles the formal documents 
that it targets for publication. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7221. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The productive output of an IETF working group (WG) is documents, as 
mandated by the working group’s charter. Working groups develop 
these documents based on initial input at varying levels of maturity. 
An initial working group draft might be a document already in wide 
use, or it might be a blank sheet, wholly created by the working 
group, or it might represent any level of maturity in between. This 
document discusses how a working group typically handles the formal 
documents that it targets for publication. The discussion applies 
only to the IETF and does not cover IRTF groups, where practices vary 
widely. 
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Within the general constraints of formal IETF process and the 
specific constraints of a working group’s charter, there can be 
considerable freedom in the adoption and development of drafts. As 
with most IETF activities, the ultimate arbiter of such choices is 
working group agreement, within the constraints of its charter. As 
with most working group management, this agreement might be explicit 
or implicit, depending upon the efficiencies that the group deems 
appropriate. 


NOTE: This document is intentionally non-normative. It is meant as 
a guide to common practice, rather than as a formal definition of 
what is permissible. 


1.1. What Is a WG Draft? 


Working group drafts are documents that are subject to IETF working 
group revision control, with advancement for publication as an RFC 
requiring rough consensus in the working group and then in the 
broader IETF. Creation or adoption of a draft by a working group -- 
as well as substantive changes to the document -- need to represent 
working group rough consensus. 


Documents under development in the IETF community are distributed as 


Internet-Drafts (I-Ds) [RFC2026] [ID-Info]. Working groups use this 
mechanism for producing their official output, per Section 7.2 of 
[RFC2418] and Section 6.3 of [Tao]. The common convention for 


identifying an I-D formally under the ownership of a working group is 
by the inclusion of "ietf" in the second field of the I-D filename 
and the working group name in the third field, per Section 7 of 
[ID-Guidelines]. That is: 


draft—ietf-<wgname>-... 


In contrast, individual submissions are drafts being created and 
pursued outside of a working group, although a working group might 
choose to adopt the draft later, as discussed below. Anyone is free 
to create an individual submission at any time. Such documents are 
typically distinguished through the use of the author/editor’s last 
name, in the style of: 


draft-—<lastname>-... 
(Also see Section 5.1 for an elaboration on this naming.) 
Responsibility for direct revision of a working group I-D is assigned 


to its editors and authors. See Section 3 for discussion about their 
selection and role. 
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1.2. Working Group Authority and Consensus 


A premise of the IETF is that, within a working group, it is the 
working group itself that has final authority over the content of its 
documents, within the constraints of the working group’s charter. No 
individual has special authority for the content. The Chairs assign 
document authors/editors and can formulate design teams, but the 
content of working group documents is always, ultimately, subject to 
working group approval. Approval is described in terms of the IETF’s 
"rough consensus" construct, which is the prime example of the IETF’s 
preference for pragmatics over niceties. Unanimous agreement is 
always desirable, but more approximate (rough) agreement will 
suffice, as long as it is clear and strong. 


Other than for selection of document authors/editors, as discussed in 
Section 3, working group decision-making about document management is 
subject to normal IETF rough consensus rules. Useful descriptions of 
this process for a working group are in Section 3.3 of [RFC2418] and 
Section 4.2 of [Tao]. Discussion of the nature of rough consensus 
can be found in [Consensus]. 


In terms of the IETF’s formal rough consensus processes, the working 
group explicitly develops, modifies, reviews, and approves document 
content, according to overt rough consensus. For difficult topics 
and/or difficult working group dynamics, this laborious process 
really is essential. Its diligence validates progress at each step 
along the way. However, working groups often handle simpler matters 
more simply, such as allowing a Chair to assert the likely agreement 
and then merely call for objections. Ultimately, the mode of working 
group decision-making is determined by the comfort and engagement of 
the working group with the way the decisions are being made. 


At times, a document author/editor can appear to have considerable 
authority over content, but this is (merely) for efficiency. That 
is, the Chairs can permit authors and editors to proceed with an 
implied (default) working group agreement, as long as the working 
group is comfortable with that mode. Of course, the benefit in the 
mode is efficiency, but its risk is failure to retain or verify 
actual consensus among the working group participants. Whena 
working group is operating in the mode of active, direct author/ 
editor content development, an easy validation method is simply to 
have Chairs query the working group when a new document version 
appears, asking for comments and concerns. 
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In general, when it is not completely obvious what the opinion of the 
working group is, Working Group Chairs can poll the working group to 
find out. As with any other consensus question, the form in which it 
is asked can make a difference. In particular, a general ‘yes/no’ 
question often is not as helpful as asking supporters and detractors 
of a draft -- or of the decision under consideration -- to provide 
their reasons, not merely their preferences. In effect, this treats 
the matter of consensus as an ongoing discussion. Ideally, the 
discussion can produce changes in the document or in participant 
views, or both. 


1.3. Questions Considered in This Document 
The purpose of this document is to discuss the criteria and sequence 
typically followed when adopting and developing a formal IETF working 
group document. Therefore, this document considers the following 
questions that are particularly relevant to Working Group Chairs who 
are charged with running the process: 


* How do Working Group Chairs decide which drafts to adopt and when? 


* Is it necessary to poll the working group explicitly, and what 
does a working group poll look like? 


* How do Working Group Chairs make the decision? 


* What are the process steps the working group will choose to use, 
for an I-D to become a WG I-D? 


* Are there any special cases? 
* Can a document be created as a WG I-D from scratch? 


* How can competing drafts be handled? 


* Can an individual I-D be under the care of a WG? 


* Can a WG I-D become an individual I-D? 
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Adoption Sequence 


Common Steps 


When there is interest in adopting a document as a new working group 
document, the Chairs often: 


Ts 


282. 


Remind current draft owners that they are transferring change 
control for the document to the IETF. (This is a particularly 
significant point for a document covered by proprietary 
interests, because it typically entails a negotiation between the 
current owners and the IETF, including a formal agreement.) 


Check for known IPR that needs to be disclosed, using some 
technique like those described in [RFC6702]. 


Obtain working group rough consensus. 
Choose document editors. 

Instruct authors to post the WG I-D. 
Approve posting [Approval]. 


Ensure that the non-working group version of the draft is marked 
as being replaced by this working group version. 


Encourage everyone to enjoy the ensuing working group 
discussion... 


Criteria for Adoption 


No formal specification for working group ’adoption’ of a draft 
exists; the current document is meant to provide a description of 
common activities for this, but again note that it is not normative. 


There are some basic considerations when deciding to adopt a draft: 


* 


Is there a charter milestone that explicitly calls for sucha 
document? 


Is the topic of the I-D within scope for the working group? 
Is the purpose of the draft sufficiently clear? 


Does the document provide an acceptable platform for continued 
effort by the working group? 
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* What are the process or technical objections to adoption of the 
draft? 
* Is the draft likely to be completed in a timely manner? 


* Does the intended status of the document seem reasonable to the 
working group? 


* If not already in scope, is a simple modification to the charter 
feasible and warranted? 


* Does the draft carry known intellectual property rights issues? 
* Is there strong working group support for working on the draft? 
Adoption has some basic pragmatics: 


Rough consensus: Working group agreement to adopt is not required 
to be unanimous [RFC2418]. 


Initial, not final: The writing quality is not required to be 
"ready for publication", although writing quality can be a 
problem and does need explicit attention; although not 
mandatory, it is good practice to check whether a new working 
group draft passes [IDNITS]. 


Adoption, not approval: The document is not required to already 
contain a complete and/or sufficient solution, although of 
course this can be helpful. Equally, adoption by a working 
group does not guarantee publication of the document as an RFC. 


Group, not Chairs: Concerning the draft, the position of the 
Working Group Chairs has no special authority, except to assess 
working group consensus. 


REMINDER: Once a working group adopts a draft, the document is owned 
by the working group and can be changed however the working group 
decides, within the bounds of IETF process and the working group 
charter. Absent explicit agreement, adopting a document does not 
automatically mean that the working group has agreed to all of its 
content. So a working group (or its charter) might explicitly 
dictate the basis for retaining, removing, or modifying some or 
all of a draft’s content, technical details, or the like. 

However, in the absence of such constraints, it is worth having 
the adoption process include a sub-process of gathering working 
group concerns about the existing draft and flagging them 
explicitly. 
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3. Authors/Editors 


Document authors/editors are chosen by the Working Group Chairs. 
Document editors are described in Section 6.3 of [RFC2418]. Authors 
and editors are described in [RFC-Auth-Ed]. 


NOTE: In this document, the terms ’author’ and ’editor’ are meant 
interchangeably. Within the IETF, the distinction between an 
‘author’ and an ’editor’ is, at best, subjective. A simplistic 
rule of thumb is that editors tend to do the mechanics of 
incorporating working group detail, whereas authors tend to create 
the detail, subject to working group approval. That is, one role 
is more active with the content, and the other is more passive. 

It is a responsibility of the Working Group Chairs to ensure that 
document authors make modifications in accord with working group 
rough consensus. Authors/editors are solely chosen by the Chairs 
-- although the views of the working group should be considered -- 
and are subject to replacement for a variety of reasons, as the 
Chairs see fit. 


For existing documents that are being adopted by a working group, 
there is a special challenge in the selection of document editors. 
Because the document has already had editors, the question "Are the 
same people appropriate for continuing the task?" is asked. 
Sometimes the answer is yes, but this is not automatic. The process 
within an IETF working group can be quite different from the process 
that created previous versions. This well might make it appropriate 
to select one or more new editors, either as additions to the editor 
team or as primary pen-holders (effectively reclassifying the 
previous team as coauthors). 


If the original editors are to continue in their role, the Chairs 
might want to ensure that the editors understand IETF working group 
process; it is likely to be quite different from the process that 
developed earlier versions of the document. If additional or new 
editors are assigned, the transition can be discussed, including its 
reasons; this is best done as soon as possible. 


4. Document History and Stability 


Working group charters sometimes specify an initial set of existing 
documents to use as a basis of the working group’s activities. That 
‘basis’ can vary considerably, from simple input to working group 
discussion, all the way to an advanced draft adopted by the working 
group and subject only to minimal changes. The role of a document 
should be explicitly stated in the charter. 


Farrel & Crocker Informational [Page 8] 


RFC 7221 Handling of I-Ds by WGs April 2014 


Within the scope of its charter, a working group is free to create 
new documents. It is not required that all drafts start as the 
effort of an individual. Of course, the criteria for brand new 
documents are likely to be the same as for those imported into the 
working group, with the additional and obvious requirement that the 
Working Group Chairs will need to appoint authors/editors before any 
work can progress. Note that, from time to time, a working group 
will form a design team to produce the first version of a working 
group draft. Design teams are discussed in Section 6.5 of [RFC2418]. 


Work that is brought to the IETF has different levels of completeness 
and maturity, and different timings for having achieved those levels. 
When the IETF charters a group and includes existing material, the 
charter can cast the role of that material in very different ways. 

It can treat it as: 


* no more than a set of ideas, to be used or ignored; 
* a basic design, with all of the actual details still fluid; 
* a rough draft, subject to extensive revision; 


* a solid specification that merely needs review, refinement, and 
maybe enhancement; 


* a deployed technology that is best served by trying to protect its 
installed base, but with some tolerance for changes that affect 
interoperability; 


* a deployed technology for which protecting the installed base is 
essential, including retention of core interoperability. 


These suggest a wide range of possible constraints on working group 
effort. Technology is brought to the IETF at different points of 
maturity along its life cycle, and the nature of the technology can 
have widely varying utility in developing an Internet standard. 


When technology is brand new, with at most some prototypes done as 
proofs of concept, then significant changes to the specification will 
not necessarily add much to the development and deployment costs. 
However, when the technology is already part of a mature and 
extensive operational deployment, any changes that are incompatible 
are likely to be problematic for that market and can hinder adoption 
of the changes overall. For example, immediately after the 
development investment is made -- and especially when there has been 
considerable initial deployment but there is still room for quite a 
bit more -- the installed and potential base might not take kindly to 
disruptive standards work that undermines their recent investment. 
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Conversely, even a deployed technology with a solid base might be 
inappropriate to deploy at Internet scale, and while a document 
specifying such a technology might serve as a good starting point on 
which to base a new specification, undermining of the deployed base 
might be completely appropriate. 


In reflecting upon the basis for adopting an existing draft and the 
way it will be used by the working group, it is important to consider 
the document’s place in its life cycle, the needs of any installed 
base, and the applicability of the draft’s technology, when deciding 
on the constraints to impose on document development. It will all 
depend on the constraints of the charter and the analysis of the 
working group. 


Some Issues for Consideration 
Ly Individual I-Ds under WG Care 


Sometimes, a working group facilitates a draft but does not own it or 
formally adopt it. These are "individual" drafts [Individual]. 


As noted in Section 1.1 and reinforced in [ID-Guidelines], the 
convention for identifying an I-D formally under the ownership of a 
working group is by following the naming convention: 


draft—ietf-<wgname>-... 


By contrast, documents that are still under the control of their 
authors are known as "individual" I-Ds. When these documents are 
intended for consideration by a specific working group, the 
convention is that the document uses the naming convention as 
follows, where the second element is the last name of one of the 
principal authors. 


draft-—<lastname>-<wgname>... 


Having the working group name following the personal name allows 
tools to associate these drafts with the working group, even though 
the filename identifies them as the work of individuals. 


The working group can choose to apply any of its normal, internal 
working group process management mechanisms to an individual I-D. 
However, matters of ownership, working group final approval, and the 
like are all subject to negotiation amongst the document authors, 
working group, and Area Directors. 
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This is a rare situation, and Working Group Chairs can be assured 
that the Area Directors will want to understand why the document 
could not be adopted and owned by the working group. 


5.2. WG Drafts Can Become Individual Drafts 


A working group is not obligated to retain documents it has adopted. 
Sometimes working group efforts conclude that a draft is no longer 
appropriate for working group effort. If a working group drops a 
draft, then anyone is permitted to pursue it as an Individual or 
Independent Submission, subject to the document’s existing copyright 
constraints. 


5.3. Competing Drafts 


Engineering for interesting topics often produces competing, 
interesting proposals. The reasons can be technical aesthetics, 
engineering trade-offs, architectural differences, company economics, 
and the like. Although it is far more comfortable to entertain only 
one proposal, a working group is free to pursue more than one. Often 


this is necessary until a clear preference develops. Sometimes, 
multiple versions are formally published, absent consensus among the 
alternatives. 


It is appealing to ask authors of competing proposals to find a way 
to merge their work. Where it makes sense to do this, it can produce 
a single, strong specification. The detailed discussions to merge 
are often better held in a design team than amidst the dynamics of an 
open working group mailing list. The working group has ultimate 
authority over any decisions, but it is not required that it be 
involved in all the discussions. 


On the other hand, some differences cannot be resolved, and 
attempting a merge can produce a weaker result. An example of this 
problem of conflicting design goals is discussed in [Heli-Sub], 
noting: 


"Helicopters are great, and so are submarines. The problem is 
that if you try to build one vehicle to perform two fundamentally 
different jobs, you’re going to get a vehicle that does neither 
job well." 
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Various management efforts can facilitate the handling of competing 
proposals. Some examples include: 


* Developing a requirements document that is independent of specific 
proposals; this can highlight features that are deemed essential 
and distinguish them from features that are of secondary 
importance, and can facilitate a discussion about features without 
reference to specific proposals. 


* Developing a comparison table of the proposals; this can aid 
understanding of their differences. 


* Discussing the relative importance and effects of having one 
proposal, versus multiple; this can focus people’s efforts at 
compromise and encourage a willingness to choose a single 
proposal. 


The problem of competing drafts can be particularly painful when it 
arises in either of two circumstances: 


* If a second proposal appears as a new draft, just as the Chairs 
were ready to poll the working group on adoption of the draft 
containing the first proposal, then the authors of the first 
proposal could feel affronted. It does not follow that the second 
draft was written to be difficult or derail the first: it might 
even include better ideas. So it is best not to disregard it. 
However, automatically asking the authors to merge their work will 
not necessarily produce a more solid solution and will not 
guarantee faster progress. This situation will be a judgement 
call in each case, and it might help to ask the working group for 
their opinion: shall the working group adopt one document as a 
starting point and fold in the ideas from the second under the 
control of consensus, or shall the working group wait until the 
authors of both documents have reached agreement? 


* If the working group has already adopted an I-D on a specific 
topic, the posting of a new individual I-D on the same topic could 
be seen as an attack on the working group processes or decisions. 
However, posting an I-D is often a good way to put new ideas into 
concrete form, for public consideration and discussion. The 
Working Group Chairs will want to encourage the working group to 
consider the new proposal. Shall it be adopted and entirely 
replace the current working group draft? Shall the new ideas be 
incorporated into the work of the working group through the normal 
editorial process? Shall the working group adopt a second 
competing solution? Or shall the new draft be rejected and not 
adopted by the working group? 
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6. Security Considerations 


Beyond the credibility of the IETF, this document raises no security 
concerns. 
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